The invention relates to voice over Internet protocol (VOIP) communications, and more specifically to systems and methods for handling the processing of multiple Session Initiation Protocol (SIP) transactions that have been requested at substantially the same time while a dialog is being conducted between two VOIP software applications.
FIG. 1 illustrates an environment in which a first IP telephony software application 102 is able to conduct an IP telephony communication with a second IP telephony software application 104 via a data network 120. The data network 120 could be the Internet, or any other data network through which the first and second IP telephony software applications can communicate. An IP telephony service provider 110 may facilitate the setup, conduct and termination of the IP telephony communication.
Each of the first and second IP telephony software applications 102, 104 could be resident on any type of computer processing device. For example, each of the first and second IP telephony software applications 102, 104 could be resident on a laptop or desktop computer, on a personal data assistant, on a smart phone, or on any other stationary or portable computing device capable of running the IP telephony software application.
The IP telephony communication that is conducted between the first and second IP telephony software applications 102, 104 could be an IP-based audio telephone call, an IP-based video call, an exchange of SMS or MMS messages, or some other type of IP-based communication.
There are many different IP-based communication protocols that can be used to establish such IP communications. Currently, one of the most commonly used protocols is the Session Initiation Protocol, which is commonly called “SIP.” SIP is a signaling protocol for initiating, managing and terminating media (e.g., voice, data and video) sessions across packet based data networks that typically use the Internet Protocol (IP), of which VOIP is an example. The details and functionality of SIP can be found in the Internet Engineering Task Force (IETF) Request for Comments (RFC) Paper No. 3261 entitled, “SIP: Session Initiation Protocol” herein incorporated in its entirety by reference. SIP establishes and negotiates a session, including the modification or termination of a session. It uses a location-independent address system feature in which called parties can be reached based on a party's name. SIP supports name mapping and redirection, allowing users to initiate and receive communications from any location.
When a new communication session is established between two IP telephony software applications, the session is commonly referred to as a “dialog.” While a dialog is ongoing between two software applications, the two software applications can exchange messages with one another, or modify aspects of the dialog, using certain predetermined, formatted requests. Examples of such SIP requests include INVITE, BYE, REFER and UPDATE.
Typically, when a first, initiating software application sends a request to a second software application, the second software application sends back a response. The first software application may then send an acknowledgment back to the second software application to indicate that the response was received. This sequence of messages, which includes the initial request, a response, and an acknowledgment, are typically referred to as a “transaction.” Of course, some transactions only involve a request and a response, such as a BYE transaction.
One characteristic of SIP is that only a single transaction can be processed at any given time by two software applications that are engaged in a dialog. This aspect of SIP can cause a variety of problems if one or both of the software applications requests the processing of multiple SIP transactions at substantially the same time.
For example, assume that first and second IP telephony software applications are engaged in a dialog in the form of an audio telephone call. Assume that the first software application requests the processing of a transaction that will upgrade the audio call to a video call. As a result, a request is sent from the first software application to the second software application indicating that the call is to be upgraded to a video call. Then, before the second software application can send back a response, the first software application determines that it is necessary to place the audio call on hold. This could occur for a variety of reasons, including the receipt of a request from a user to place the call on hold. In this scenario, before processing of the first transaction (to upgrade the audio call to a video call) can be completed, the first software application attempts to send a second request to place the audio call on hold. Because SIP only allows the processing of a single transaction at any given time, processing of the second requested transaction (to place the call on hold) will fail.
Unfortunately, this sequence of events may result in the first software application actually placing the call on hold while the second software application is unaware that the call has been placed on hold. This can result in considerable confusion on the part of the user of the second software application, as it will appear to that user that the call has been prematurely terminated.
Another situation that can be problematic is when first and second software applications are engaged in a SIP dialog, and both the first and second software applications request the processing of transactions at substantially the same time. For example, assume that the first software application requests the processing of a first transaction, and a request message is sent from the first software application to the second software application. However, instead of receiving a response to that request back from the second software application, the first software application receives a request message from the second software application, because the second software application has also requested the processing of a transaction at substantially the same time. Under these circumstances, the first software application would likely send an abort message back to the second software application indicating that the second request must be aborted. The first software application then continues to wait for a response to the first request that it initiated. That response may or may not be forthcoming, depending on whether the second software application received the first request before it began to process the second request for a transaction that it initiated.
Ideally, the second software application will respond to the first request initiated by the first software application, and processing of the first transaction will be successfully completed. The second software application will thereafter re-send its second request for a transaction, and processing of the second transaction also will be completed. However, it is also possible that the second software application never responds to the first request initiated by the first software application. Thus, when two software applications engaged in a SIP dialog both attempt to initiate transaction requests at substantially the same time, various problems can occur.
What is needed is a way to handle multiple SIP transaction requests that are made at substantially the same time—either by a single software application engaged in a dialog, or by two software applications that are engaged in a dialog.